Email management software has been an integral part of the modern business world. Email management software such as LOTUS NOTES® and MICROSOFT® OUTLOOK® allow users to store messages, email addresses, and other contact information. The email management software stores the user's email and contact data in an email management software database (database), usually on a separate server computer. In large companies, the database can be large and requires frequent maintenance by information technology (IT) professionals.
When performing maintenance on a server containing a database, IT professionals typically move the database to another server. This occurs when an IT professional has to replace a server or when a plurality of servers are being load balanced. Even when the IT professional is not maintaining the server, the IT professional may find it useful to move the database to a new server in order to make room for other programs on the old server or make the computer network run more efficiently.
One of the features of email management software is that the email management software distinguishes between read and unread email. The email management software distinguishes between read and unread messages by bolding the unread messages, by placing an unopened envelope next to the unread messages, or by some similar iconic or font change to the message. The icon or font change allows a user to discern which messages he has read and which messages he has not read. Within the database is a read/unread table that stores the data that indicates whether the user has read his messages in his mailbox.
Problems arise from the interaction of the email management software with the read/unread table. One problem is that the read/unread table may contain large amounts of document data. This is a problem because the read/unread table needs to be small in order for the email management software to operate efficiently. The email management software also requires the read/unread table to be in a fixed location within the database, limiting configuration options within the database. Therefore, a need exists for a read/unread table that is both small and fixed within the database.
As seen in FIG. 1, the solution to these problems is to fix the position of read/unread table 120 in the database and fill read/unread table 120 with a plurality of handles, called note IDs, instead of the document data 160. Read/unread table 120 contains a note ID for every unread message. The note IDs are four bytes in size and thus only contain enough information to point to a fixed location. The note IDs point to the location of a single universal ID within universal table 140. Universal table 140 is also in a fixed location within the database. Universal table 140 contains universal IDs, which are pointers that point to document data 160. The universal IDs are thirty two bytes in size, which is sufficient to contain all of the data required to point to document data 160 even when document data 160 is moved from one location to another. In other words, the universal IDs in universal table 140 contain the information required to find document data 160 when it is moved. Thus, the present configuration allows the email management software to run efficiently by only accessing a small, fixed read/unread table, allows document data 160 to be moved within the database, and allows the email program to find document data 160 through a series of pointers.
One of the problems that IT professionals encounter when moving the database from a source server to a destination server is that read/unread table 120, universal table 140, and/or document data 160 get reorganized during the move to the source server. As illustrated in FIG. 2, this reorganization causes a loss of integrity in the association between the note IDs in read/unread table 120 and document data 160 because the note IDs and the universal IDs become misaligned when they are moved from the source server to the destination server. In other words, read/unread table 120 is specific to a single server. As an example, in FIG. 1 note ID 1 is associated with document D, note ID 2 is associated with document C, and so forth. However, when the database is moved to a destination server (See FIG. 2), note ID 1 becomes associated with document B, note ID 2 becomes associated with document D, and so forth. Thus, when the database is moved, the database in the destination server shows a different read/unread status for each of the messages in the source database. The loss of integrity of the read/unread status in the email management software is disruptive to the user. Consequently, a need exists for a method for preserving the read/unread status for a plurality of messages when a database is moved from a source server to a destination server.
The prior art solution to the loss of integrity problem identified above is cumbersome and error prone. The prior art solution is to send an email to the user giving the user instructions on how to manually relate the note IDs in read/unread table 120 in the source database to the universal IDs in universal table 140 in the destination database. The user must perform a plurality of steps in a menu to relate the read/unread table in the source database with the restructured email data in the destination database. Failure by the user to correctly relate the read/unread table to the email data causes an error or inaccurately displays the read/unread data. Consequently, a need exists for a method for automatically preserving the read/unread status of a plurality of messages when a database is moved from a source server to a destination server.